During a transaction using a transaction card, such as a credit card, a debit card, a stored value card, a bank card, a loyalty card, a smart card and/or the like, it is important to verify a cardholder's ownership of an account to avoid a variety of problems, such as unauthorized use. Cardholder authentication is the process of verifying that the account is owned by the cardholder. For example, cardholder authentication during a “card present” transaction is performed when a merchant's representative verifies that the signature on a transaction card matches the cardholder's signature on a receipt.
Technological improvements have allowed businesses and individuals to engage in transactions in a plurality of environments. For example, cardholders can engage in traditional “in person” transactions, transactions via the Internet, transactions over the telephone and transactions through mail systems. In many cases, cardholders desire the convenience of performing transactions without having to directly visit a service provider. In doing so, the cardholder may seek to eliminate transportation time and reduce the hassle associated with, for example, shopping in a retail environment or waiting in line at a bank by performing these transactions from the privacy of their own home.
“Card not present” (“CNP”) transaction volumes are increasing at least in part because of such convenience provided to cardholders and the extra sales provided to merchants. However, as CNP transaction volume increase, fraudulent transactions and the monetary losses due to such transactions are increasing as well.
FIG. 1 depicts a system diagram for a conventional transaction processing system according to the prior art. As shown in FIG. 1, a transaction processing system is logically divided into an issuer domain 110, an interoperability domain 120 and an acquirer domain 130. The issuer domain 110 includes a consumer 112 and an access control server 114 (“ACS”). The interoperability domain 120 includes a directory server 122 (“DS”) and an authentication history server 124 (“AHS”). The acquirer domain 130 includes a merchant purchase interface 132 (“MPI”) and an acquirer bank 134. The lines represent data transfers performed between the connected entities. Such data transfers are described more fully below in reference to FIG. 2.
FIG. 2 depicts a conventional CNP transaction flow according to the prior art. As shown in FIG. 2, a consumer adds items to a shopping cart and finalizes 205 a transaction. The MPI 132 sends 210 an enrollment verification request to a DS 122 to verify enrollment of the consumer 112. If the consumer's card number is within a card range participating in authentication, the DS 122 forwards 215 the request to the ACS 114. The ACS 114 responds 220 to the DS 122 with an enrollment verification response indicating whether authentication is available for the card number. The DS 122 then forwards 225 the enrollment verification response to the MPI 132. If the consumer's card number is not within a participating card range, the DS 122 creates and sends 230 a response to the MPI 132.
If card authentication is available, the MPI 132 sends 235 a request for payer authentication to the ACS 114 via the consumer's Internet browser 112. The ACS 114 receives 240 the payer authentication request and authenticates 245 the consumer 112 as appropriate for the card number. For example, the consumer 112 could be authenticated using a password, chip cryptogram, personal identification number or the like. The ACS 114 formats 250 and, optionally, digitally signs a response to the payer authentication request. The ACS 114 then transmits 255 the response to the MPI 132 via the consumer's Internet browser 112. In addition, the ACS 114 can transmit 260 a copy of the response (in the form of a payer authentication transaction request) to an AHS 124.
The MPI 132 then receives 265 the payer authentication response and validates 270 the response signature if the response signature was signed by the ACS 114. The MPI 132 then commences 275 an authorization exchange with its acquirer 134.
One problem with addressing fraud is determining how to provide early warning to merchants and issuers that fraud is occurring with a particular consumer's account number. Without an alert that fraud is taking place, the fraudster can continuously submit fraudulent transactions using the account number.
A need exists for methods and systems for providing early warning detection for suspicious activity.
A need exists for methods and systems for reporting suspicious activity related to CNP transactions.
A further need exists for methods and systems for providing an alert to an issuer that is not actively managing its CNP transaction processing system or authorization logic.
The present disclosure is directed to solving one or more of the above-listed problems.